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Abstract. We present a rewriting algorithm for efficiently testing future 
time Linear Temporal Logic (LTL) formulae on finite execution traces. 
The standard models of LTL are infinite traces, reflecting the behavior 
of reactive and concurrent systems which conceptually may be continu- 
ously alive. In most past applications of LTL, theorem provers and model 
checkers have been used to formally prove that down-scaled models sat- 
isfy such LTL specifications. Our goal is instead to use LTL for up-scaled 
testing of real software applications, corresponding to analyzing the con- 
formance of finite traces against LTL formulae. We first describe what 
it means for a finite trace to satisfy an LTL property and then suggest 
an optimized algorithm based on transforming LTL formulae. We use 
the Maude rewriting logic, which turns out to be a good notation and 
being supported by an efficient rewriting engine for performing these ex- 
periments. The work constitutes part of the Java PathExpiorer (JPaX) 
project, the purpose of which is to develop a flexible tool for monitoring 
Java program executions. 


1 Introduction 

Future time Linear Temporal Logic (future time LTL), introduced by Pnueli 
in 1977 [21], is a logic for specifying temporal properties about reactive and 
concurrent systems. Future time LTL provides temporal operators that refer to 
the future/remaining part of a trace relative to a current point of reference. We 
shall use the shorthand LTL when it is clear from the context that we mean 
future time LTL. The models of LTL are infinite execution traces, reflecting the 
behavior of such systems as ideally always being ready to respond to requests, 
operating systems being an example. LTL has typically been used for specifying 
properties of concurrent and interactive down-scaled models of real systems, such 
that fully formal program proofs could subsequently be carried out, for example 
using theorem provers [14] or model checkers [9]. However, such formal proof 
techniques are usually not scalable to real sized systems without an extra effort 
to abstract the system to a model which is then analyzed. Several systems are 
currently being developed that apply model checking to software [4] [15] [3] [20] 
[6] [24], including our work wx>rk [10] [25]. In this paper we restrict ourselves 
to investigate the use of LTL for testing whether single finite execution traces 
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An important .piestion is how to efficiently test LTL formulae of finite trace 
tnodels, and the main decision here is what data structure one should use to 
represent the formula such that it. can be used to efficiently analyze the trace 
ms it is traversed. We will present such a data structure. We will present and 
implement our logics and algorithms in Maude [I], a high-performance system 
supporting both membership equational logic [19] and rewriting logic [ IS] . The 
current version of Maude can do up to 3 million rewritings per second on 300MHz 
processors, and its compiled version is intended to support 1-5 million rewritings 
per second . The decision to use Maude has made it very easy to experiment 
with logics and algorithms. Later realizations of the work can be done in a 
standard programming language such as Java or C++. In [13] we have for ex- 
ample described a data structure used to represent an LTL formula as a minimal 
finite state machine, based on a concept called finite transition trees. This struc- 
ture can then be represented and interpreted within Java. In [22] we further- 
more describe a dynamic programming algorithm for checking LTL formulae on 
execution traces. Our colleague Dimitra Giannakopoulou has furthermore im- 
plemented a Buchi automata inspired algorithm adapted to finite trace LTL. 
However, so far the speed of Maude is very promising, suggesting that Maude 
can be used not only for prototyping but also for practical monitoring. 

The work constitutes part of the Java PathExplorer (JPaX) tool [12, 13] for 
monitoring Java program executions. JPaX facilitates automated instrumenta- 
tion of Java byte code, which then emits events to an observer during execution. 
The observer can be running a Maude process as a special case, hence Maude’s 
rewriting engine can be used to drive a temporal logic operational semantics 
with program execution events. JPaX can be regarded as consisting of three 
main modules: an instrumentation module, an observer module, and an inter- 
connection module that ties them together through the observed event stream, 
see Figure 1. The instrumentation module performs a script-driven automated 
instrumentation of the program to be observed, using the bytecode engineering 
tool Jtrek [2]. The instrumented program, when run, will emit relevant events to 
the interaction module, which further transmits them to the observation mod- 
ule. The observer may run on a different computer, in which case the events are 
transmitted over a socket. When the observer receives the events it dispatches 
these to a set of observer rules, each rule performing a particular analysis that 
has been requested in the verification script. Observer rules are written in Java, 
but can call programs written in other languages, such as in this case Maude. In 
addition to checking such high level requirements, rules can also be programmed 
to perform low level error pattern analysis of, for example, multi-threaded pro- 
grams, identifying error-prone programming practices, such as unhealthy locking 
disciplines that may lead to data races and/or deadlocks. The specification script 
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Fig. 1 . Overview of JPaX 


The idea of using temporal logic in program testing is not new, and at our 
knowledge, has already been pursued in the commercial Temporal Rover tool 
(TR) [5], and in the MaC tool [If]. Both tools have greatly inspired our work. 
Our basic contribution in this paper is to show how a rewriting system, such 
as Maude, makes it possible to experiment with monitoring logics very fast and 
elegantly, and furthermore can be used as a practical program monitoring en- 
gine. This approach makes it possible to formalize ideas in a framework close to 
standard mathematics. The formula transforming approach suggested is a new 
and efficient way of testing LTL formulae. A previous version of the paper, pub- 
lished as a technical report [11], presents a simplified action based formalization 
of LTL rather than the state based more realistic framework presented here, 
which is the one currently implemented in JPaX. In [12] and [13] we describe a 
formalization of past time LTL (as well as future time LTL), again illustrating 
the succinctness of new logic definitions. 

Section 2 contains preliminaries, including an introduction to Maude, propo- 
sitional logic and the standard definition of propositional LTL with its infinite 
trace models. Section 3 presents a finite trace semantics for LTL and then its 
implementation in Maude. Although abstract and elegant, this implementation 
is not efficient, and Section 4 presents an efficient implementation using a for- 
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mul;i transformation approach. Finally. Section a contains - onclusioris ami a 
description of future work. 


2 Preliminaries 

This section briefly introduces Maude, a rewriting- based specification and ver- 
ification system, then a relatively standard procedure ro reduce propositional 
formulae, and then reminds the propositional LTL with its infinite trace models. 


2.1 Maude and Logics for Program Monitoring 

Maude [lj is a freely distributed high-performance system in the OBJ f8j alge- 
braic specification family, supporting both rewriting logic [13] and membership 
equational logic [19]. Because of its efficient rewriting engine, able to execute 
3 million rewriting steps per second on currently standard hardware configu- 
rations, and because of its metalanguage features, Maude turns out to be an 
excellent tool to create executable environments for various logics, modeis of 
computation, theorem provers, and even programming languages. We were de- 
lighted to notice how easily we could implement and efficiently validate our 
algorithms for testing LTL formulae on finite event traces in Maude, admittedly 
a tedious task in C-f-4- or Java, and hence decided to use Maude at least for the 
prototyping stage of our runtime check algorithms. 

We very briefly and informally remind some of Maude's features, referring 
the interested reader to the manual [1] for more details. Maude supports mod- 
ularization in the OBJ style. There are various kinds of modules, but we are 
using only functional modules which follow the pattern ; ‘fmod <name> is <body> 
endfm”. The body of a functional module consists of a collection of declarations, 
of which we are using importing, sorts, subsorts, operations, variables and equa- 
tions, usually in this order. 

W/e next introduce some modules that we think are general enough to be used 
within any logical environment for program monitoring that one would want to 
implement by rewriting. The next one simply defines atomic propositions as an 
abstract data type having one sort, Atom and no operations or constraints: 

fmod ATOM is sort Atom . andfm 

The actual names of atomic propositions will be automatically generated in an- 
other module that extends ATOM, as constants of sort Atom. These will be generated 
by the observer at the initialization of monitoring, from the actual properties 
that one wants to monitor. 

An important aspect of program monitoring is that of an (abstract) execution 
trace, which consists of a finite list of events. We abstract events by lists of atoms, 
those that hold after the action that generated the event took place. The values 
of the atomic propositions are updated by the observer according to the actual 
state of the executing program and then sent to Maude as a term of sort Event: 
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The statement protecting ATOM imports the module ATOM. The above is a com- 
pact way to use mix- fix 2 and order-sorted notation to define an abstract data 
type of traces: a trace is a comma separated list of events, where an event is just 
a list of atoms. Operations can have attributes, such as the precedences above, 
which are written between square brackets. The attribute prec gives a prece- 
dence to an operator 3 , thus eliminating the need for most parentheses. Notice 
the special sort Fvent* which stay for terminal events, i.e., events that occur at 
the end of traces. Any event can potentially occur at the end of a trace. It is 
often the case that ending events are treated differently, like in the case of finite 
trace linear temporal logic; for this reason, -we have introduced the operation 
which marks an event as terminal. 

Syntax and semantics are basic requirements to any logic, in particular to 
those logics needed for monitoring. The following module introduces what we 
believe are the basic ingredients of monitoring logics. We found the following 
very useful for our logics, but of course, the user is free to change it if he/she 
finds it inconvenient: 

fmod LQGICS-BASIC ia protecting TRACE . 
sort Formula . subaort Atom < Formula . 
op* true false : -> Formula . 
op [_J : Formula -> Bool [strat (1 0)] 
eq [true] ■ true . eq [false] * false . 

vars A A’ : Atom . v ar E : Event . var E* : Event* . var T : Trace . 
op _{_}■ : Formula Event* -> Formula [prec 10] 
eq true{E*> * true . eq false{E*> 3 false . 
eq A{nil} » false . 

eq A{A’> * if A ** A 1 then true else false fi . 

eq A{A’ E> * if A ** A’ then true else A<E> fi . 
eq A{E *> » A<E> . 

op : Trace Formula -> Bool [prec 30] 

eq T !* true * true . 
eq T |* false * false . 
eq E I 3 A 3 [A<£>] . 
eqE,TI*A=*E)-A . 
endf m 


The first block of declarations introduces the sort Formula which can be thought 
of as a generic sort for any well-formed formula in any logic. There are two 
designated formulae, namely true and false, with the obvious meaning, together 
with a “projection'’, denoted [_], of any formula into a boolean expression. The 
only role of this operation is to check whether a logical formula is violated or not, 
each logic being allowed to refine this operator according to its policy; the sort 
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3ool is Imiir.in to Maude .uid has two constants true and false which an* dilfWrnt 
fmrn those «>t sort Formula, and a generie operator Lf_then.else.fi. Its attribute 
'>«l\ s ‘.hat this ( )p<Tuti< ais should always be evaluated eagerlv: munhers in t, h t ' 
otiategv det filiation stay for argument positions that are numbered from left to 
ri^ht, (J staying tor the operator itself. The definition of [_] can be extended 
within other further logics if needed, like in the case of proposition calculus (see 
next subsection). The second block defines the operation _{_} which takes a 
formula and an event and yields another formula. The intuition for this operation 
is that it evaluates the formula in the new state and produces a proof obligation 
as another formula for the subsequent events, if needed. If the returned formula is 
true or false then it means that the formula was satisfied or violated, regardless 
of the rest of the execution trace; in this case, a message can be returned bv the 
observer. As we 11 soon see, each logic will further complete the definition of this 
operator. Finally, the satisfaction relation is defined together with a few obvious 
properties. 

2.2 Propositional Calculus 

A rewriting decision procedure for propositional calculus due to Hsiang [16] is 
adapted and presented. It provides the usual connectives _/\_ (and), _++_ (ex- 
clusive or), _\/_ (or), (negation), (implication), and _<->_(equivalence). 
The procedure reduces tautology formulae to the constant true and all the oth- 
ers to some canonical form modulo associativity and commutativity. An unusual 
aspect of this procedure is that the canonical forms consist of exclusive or of 
conjunctions. Even if propositional calculus is very basic to almost any logical 
environment, we decided to keep it as a separate logic instead of being part of 
the logic infrastructure of JPaX. One reason for this decision is that its seman- 
tics could be in conflict with other logics, for example ones in which conjunctive 
normal forms are desired. 

An 0BJ3 code for this procedure appeared in [8]. Below we give its obvi- 
ous translation to Maude together with its finite trace semantics, noticing that 
Hsiang [16] showed that this rewriting system modulo associativity and commu- 
tativity is Church- Rosser and terminates. The Maude team was probably also 
inspired by this procedure, since the builtin 300L module is very similar. 

faod PROP-CALC is artending LOGICS-BASIC . 

••• Constructors 

°P Formula Formula -> Formula [assoc comm prsc 15] 

°P Formula Formula -> Formula [assoc comm prec 17] 

vaxs X Y Z : Formula . 

•q tru* /\ X * X . 

«q falsa /\ X » falsa . 

•q X A X - X . 

•q falsa ++ X - X . 

•q X ++ X * falsa . 

aq X A (T ♦♦ Z) ■ X A Y ♦♦ X A Z . 

Derived oparators **• 

°P -V- : Formula Formula -> Formula [assoc prec 19] . 

°P * - '■ Formula -> Formula [prec 13] . 

°P : Formula Formula -> Formula [prac 21] 

°P • Formula Formula -> Formula [prac 23] 

•q x \/ r - x a r ♦♦ x ♦♦ y . 
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Operators are again declared in mix-fix notation and have attributes between 
squared brackets, such as assoc, comm and prec <number>. Once the module above 
is loaded 4 in Maude, reductions can be done as follows: 

rad a -> b /\ r. <-> (a -> b) /\ (a -> c) •*•> true 

rad a <-> ? b «*•> a b 

Notice that one should first declare the constants a, b and c. The last six equa- 
tions are related to the semantics of propositional calculus. Since [_] _ is eagerly 
evaluated, [X] will first evaluate X using propositional calculus reasoning and 
then will apply one of the last two equations if needed; these equations will not 
be applied normally in practical reductions, they are useful only in the correct- 
ness proof in Theorem 1. 


2.3 Linear Temporal Logic 

Classical LTL provides in addition to the propositional logic operators the tem- 
poral operators CL (always), <>_ (eventually), _U_ (until), and o_ (next). An 
LTL standard model is a function t : A + — > 2^ for some set of atomic proposi- 
tions V j i.e., an infinite trace over the alphabet 2^\ which maps each time point 
(a natural number) into the set of propositions that hold at that point. The 
operators have the following interpretation on such an infinite trace. Assume 
formulae X and Y. The formula []X holds if X holds in all time points, while ox 
holds if X holds in some future time point. The formula X U Y (x until Y) holds if 
Y holds in some future time point, and until then X holds (so we consider strict 
until). Finally, o x holds for a trace if X holds in the suffix trace starting in the 
next (the second) time point. The propositional operators have their obvious 
meaning. As an example illustrating the semantics, the formula [] (x -> <>Y) is 
true if for any time point ([]) it holds that if X is true then eventually (<>) Y is 
true. Another similar property is [] (X -> o(Y U Z)), which states that whenever 
X holds then from the next state Y holds until eventually z holds. It’s standard 
to define a core LTL using only atomic propositions, the propositional operators 
(not) and _/\_ (and), and the temporal operators o_ and and then define 
all other propositional and temporal operators as derived constructs. Standard 
equations are ox =* true 0 X and []x * !<>!X. 

4 Either by typing it or using the command in <f ilenamex 
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systems using temporal logic, rests are performed on finite execution traces and 
■ Vfl therefore need to formalize? vvtiar. it means for a finite trace to satisfy an LTL 
formula. We first present a semantics of finite trace LTL using standard math- 
ematical notation. Then we present a specification in Maude of a finite trace 
semantics. Whereas the former semantics uses universal and existential quantifi- 
cation. the second Maude specification is defined using recursive definitions that 
have a straightforward operational rewriting interpretation and which therefore 
can be executed. 

3.1 Finite Trace Semantics 

As mentioned in Subsection 2.1, a trace is viewed as a sequence of program 
states, each state denoting the set of propositions that hold at that state. We 
shall outline the finite trace LTL semantics using standard mathematical nota- 
tion rather than Maude notation. Assume two total functions on traces, head : 
Trace Event returning the head event of a trace and length returning the 
length of a finite trace, and a partial function tail : Trace -+ Trace for taking the 
tail of a trace. That is, head(ej) = head(e) = e, tail(ej) = t, and length(e) = 1 
and length(ej) = 1 + length(t). Assume further for any trace £, that t x denotes 
the suffix trace that starts at position i, with positions starting at 1. The satis- 
faction relation }= C Trace x Formula defines when a trace t satisfies a formula 
ft written t j= /, and is defined inductively over the structure of the formulae 
as follows, where A is any atomic proposition and X and Y are any formulae: 

t h * iff A € head(t) 
t f= tru* iff frue, 

t )= false iff false , 

t )= I /\ Y iff t X and t {= T, 

t r I +> Y iff t |= X xor t Y p 

t h HX iff (V i < length(t)) f, i= X 

t p= ox iff (3 i < Ungtk(t)) U j= I 

1 F * H Y iff (3 i < length(t)) (t* \= T and (V j < j) t } )= X) 

f r= 0 X iff (if tail(t) is defined then tail(t) j= X else t f= X) 

Notice that finite trace LTL can behave quite differently from standard in- 
finite trace LTL. For example, there are formulae which don’t hold in infinite 
trace LTL but hold in finite trace LTL, such as <>([] A \/ [] ! A), and there 
are formulae which hold in infinite trace LTL and do not hold in finite trace LTL, 
such as the negation of the above. The formula above is satisfied by any finite 
trace because the last event/state in the trace either contains A or it doesn’t. 

3.2 Finite Trace Semantics in Maude 

Now it can be relatively easily seen that the following Maude specification cor- 
rectly “implements” the finite trace semantics of LTL described above. The 
only important deviation from the rigorous mathematical formulation described 
above is that the quantifiers over finite sets of indexes are expressed recursively. 
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.Notice that only the temporal operators needed needed declarations and seman- 
tics, the others being already defined in PROP-CALC and LGGICS-BASIC. and that 
the definitions that involved the functions head and tail were replaced by two al- 
ternative equations. One can now directly verify LTL properties on finite traces 
using Maude’s rewriting engine, by commands such as 

r«d a b, a, c a, a b t c b , a b . a, c a, a b , c b |» [] (a -> <> b) . 

rad a b, a, c a, a b, c b. a b p a, c a, a b, c b I ■ <> (! [] (a -> <> b) ) . 

which should return the expected answers, i.e., true and false, respectively. The 
algorithm above does nothing but blindly follows the mathematical definition of 
satisfaction and even runs reasonably fast for relatively small traces. For exam- 
ple, it takes 0 about 30ms (74k rewrite steps) to reduce the first formula above 
and less than Is (254k rewrite steps) to reduce the second on traces of 100 events 
(10 times larger than the above). Unfortunately, this algorithm doesn't seem to 
be tractable for large event traces, even if run on very performant platforms. 
As a concrete practical example, it took Maude 7.3 million rewriting steps (3 
seconds) to reduce the first formula above and 2.4 billion steps (1000 seconds) 
for the second on traces of 1,000 events; it couldn't finish in one night (more 
than 10 hours) the reduction of the second formula on a trace of 10,000 events. 
Since the event traces generated by an executing program can easily be larger 
than 10,000 events, the trivial algorithm above can not be used in practice. 

A rigorous complexity analysis of the algorithm above is hard (because it has 
to take into consideration the evaluation strategy used by Maude for terms of sort 
Bool) and not worth the effort. However, a simplified analysis can be easily made 
if one only counts the maximum number of atoms of the form event I* atom 
that can occur during the rewriting of a satisfaction term, as if all the boolean 
reductions were applied after all the other reductions: let us consider a formula X 
3 □ (Cl ( . . . ( □ A) . . . ) ) where the always operator is nested m times, and a 
trace T of size rc, and let T{n, m) be the total number of basic satisfactions event 
I = atom that occur in the normal form of the term T I = X if no boolean reductions 
were applied. Then, the recurrence formula T(n. m) = T(n - 1, m) 4- T(n, m - 1) 
follows immediately from the specification above. Since (™) = 
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4 An Efficient Rewriting Algorithm 

tn this section we shall present a more efficient rewriting semantics for LTL. 
based on the idea of consuming the events in the trace, one by one. and updating 
a data structure (which is also a formula) corresponding to the effect of the event 
on the value of the formula. Our decision to write an operational semantics this 
way was motivated by an attempt to program such an algorithm in Java, where 
such a solution w*ou!d be the most natural. As it turns out, it also yields a more 
efficient rewriting system. 


4.1 The Main Algorithm 


We implement this algorithm by extending the definition of the operation 
-O : Formula Event* -> Formula to temporal operators, with the following in- 
tuition. Assuming a trace E,T consisting of an event E followed by a trace T, then 
a formula X holds on this trace if and only if X{E> holds on the remaining trace T. 
If the event E is terminal then X{E *} holds if and only if X holds under standard 
LTL semantics on the infinite trace containing only the event E. 

fmod LTL-REVISED is protecting LTL . 

Tars X Y : Formula Tar E : ETent Taj - T : Trace 
•q ([] IKE) * □ X /\ X{E> . 

«q (CJ XME *> * X{E *} . 
eq (<> XME) - <> X \/ I{E> . 

•q (<> XXE *> * X{E •> . 

eq Co XME) * X . 

eq Co XME *} * X{E *} . 

eq (X U YME > * Y{E> V X{E> A X U Y . 

eq (X U YME *} » Y{E *} . 


op • Trace Formula -> Bool [strat (2 0)] . 

eq E I- X » [X{E •>] . 
eq E.T I- X * T j- X{E> . 
endfm 


The rule for the temporal operator []X should be read as follows: the formula X 
must hold now (X{E>) and also in the future ( []x). The sub-expression X{E> repre- 
sents the formula that must hold for the rest of the trace for X to hold now. As an 
example, consider the formula [] <>A. This formula modified by an event B C (so 
A doesn't hold) yields the rewritings sequence ( []<>A) {B C} -> []<>A /\ (<>A){B 
C} []<>A /\ (<>A \/ A{B C}) -> []<>A /\ «>A \/ false) []<>A /\ <>A, while 
the same formula transformed by A C (so A holds) yields ([]<>A){A C} -► 0<>A 
/\ (<>A) {A C} -f []<>A /\ (<>A \/ A{A C}) [] <>A /\ (<>A \/ true) [] <>A 

/\ true [] <>A. i.e., the same formula. Note that these rules spell out the se- 
mantics of each temporal operator. An alternative solution would be to define 
some operators in terms of others, as is typically the case in the standard se- 
mantics for LTL. For example, we could introduce an equation of the form: ox 



= tr u« i; X. .111(1 then eliminate r.hr rewriting rule for <>x m the above module. 
This turns our to be less efficient, because mure rewrites are needed. 

Hus module eventually defines a new satisfaction relation J-_ between 
.r.u es and formulae, rhe term T I- X is evaluated now by an iterative traver- 
sal over the trace, where each event transforms the formula. Note that the new 
formula that is generated in each .step is always kept small by being reduced to 
normal form via the equations in the PROP-CALC module in Subsection 2.2. In fact, 
the new formula consists of boolean combinations of subformulae of the initial 
formula, kept in a minimal canonical form. Therefore, the algorithm is linear 
in the size of the trace, and worst-case exponential in the size of the formula. 
However, it seems that this exponential complexity in the size of the formula is 
more of theoretical importance than practical, since in general the size of the 
formula grew only twice or less in our experiments. If speed is crucial and the 
above procedure turns out to be still too slow, then one can statically generate 
all formulae in which a formula can transform and store them as the states of 
an automaton, the edges being the possible events. Then when a new event is 
generated by the monitored program, one could directly go to the “next” state 
of the automaton without any logical reasoning. We have implemented an im- 
proved version of such a procedure (in which only a minimal subset of atomic 
propositions are evaluated); details regarding this implementation will appear 
elsewhere, but an informal description can be found in [13], 

Verification results are very encouraging and show that this optimized seman- 
tics is orders of magnitudes faster than the first semantics. Traces of less than 
10,000 events are verified in milliseconds, while traces of 100.000 events never 
needed more than 3 seconds. This technique scales quite well; we were able to 
monitor even traces of hundreds of millions events. As a concrete example, we 
created an artificial trace by repeating 10 million times the 10 event trace a b. 
a, c a, a b, c b, a b, a, c a, a b, c b, and then checked it against the for- 
mula [] (a -> <> b). There were needed 4.9 billion rewriting steps for a total of 
about 1,500 seconds. 


4.2 Correctness and Completeness 

In this subsection we prove that the algorithm presented above is correct and 
complete with respect to the semantics of finite trace LTL presented in Section 
3. The proof is done completely in Maude, but since Maude is not intended 
to be a theorem prover, we actually have to generate the proof obligations by 
hand. However, the proof obligations below could be automatically generated by 
a proof assistant like KUMO [;] or a theorem prover like PVS [23]®. 

Theorem 1. For any trace T and any formula X, T |= X if and only if T I- X. 

Proof. By induction, both on traces and formulae. We first need to prove two 
lemmas, namely that the following two equations hold in the context of both LTL 
and LTL-REVISED: 

We ve already done it in PVS, but we prefer to use only Maude in this paper. 
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W prove diem by structural induction on the formula X. Constants a and i arc 
needed in order to prove the first lemma via the theorem of constants. However, 
since we prove the second lemma by structural induction on X. we not only have 
to add two constants 9 and t for the universally quantified variables E and T. but 
also two other constants y and z standing for formulas which can be combined via 
operators to give other formulas. The induction hypothesis for the second lemma 
is added to the following specification as equations. Notice that we merged the 
two proofs to save space. A proof assistant like Ku.vio or PVS would prove them 
independently, generating only the needed constants for each of them. 

food PROOF -OF- LEMMAS is 
extending ITL . 
extending LTL-REVISED . 
op « : -> Event . op t : -> Trace . 
ops a b c : -> Atom . ops 7 r : -> Formula . 

«q • l» 7 * • I-7 . 

•qe I * z ■ • . 

•q «.t l« 7 ■ t 1* y{«> . 

•q • , t I- 2 * t I* 2<*> . 

«q b{*> ■ tru# . 
aq c{*> » fala* . 

•ndf a 


It is worth reminding the reader at this stage that the functionaJ modules in 
Maude have initial semantics, so proofs by induction are valid. Before proceeding 
further, the reader should be aware of the operational semantics of the operation 
namely that the two argument terms are first reduced to their normal forms 
which are then compared syntactically (but modulo associativity and commuta- 
tivity); it returns true if and only if the two normal forms are equal. Therefore, 
the answer true means that the two terms are indeed semantically equal, while 
false only means that they couldn’t be proved equal; they can still be equal. 

red (a l« a *" a i - a) and (a )■ : rue =* a I- true) 

(a I* falsa »* a |- falsa) and (a I * 7 /\ z a |- 7 /\ 2) 

and (a |« 7 ++ z >» a |- 7 ++ z) and (a 1* [] y *- a I- [] y) 

and (• !■ <> 7 *=• « j- <> y ) and (a I- 7 U z *■ a I- 7 U r) 

and (a I* o j ** a |- o j) 

and (a , t I- true *« t !■ true-Ce}) and (e,t |- falsa =- t I* false{e}> 

and (a,t I* b ** t l*» b{a>) and (e,t I- c « t |* c<a>) 

and (a,t j* 7 /\ 2 ** t |* (y /\ 2){*>) and (a.t I* y ++ z t I* (y ++ z){e}) 
and (• , t i- CJ 7 *■ * (CJ yHe}) and (e,t <>7 *■ t 1* ( <> y){e>) 

and (a , t I* 7 V z *» t I * (y U z)<a>) and (e,t i* o 7 *» t |» (o y)<e}) . 

It took Maude 129 reductions to prove these lemmas. Therefore, one can safely 
add now these lemmas as follows: 

fmod LEWHAS is 
protecting LTL . 
protecting LTL-REVISED . 

var £ : Event var T : Trace . var X : Formula 
«q E I* X * E |- K 
aq E,T X - T |- X{E> . 

• ndf a 


VVe can now prove the theorem, by induction on traces. More precisely, we show: 
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P ( T j implies /NE.T). tor .ill I'vents £ ;lih i traces T. 

when 1 P ( T; us r. ; i « ? predicate '{or all lonnulas X, T 1= X ilf T S - X litis induction 
schema can be easily formalized in Maude ,as follows: 

'mod PROOF -OF- THEOREM ls protecting LEMMAS . 

op 1 : -> Event op t : -> Tr*c9 . op z : -> Formula 

var X Formula . 

*q:l»X*tl-X. 

«ndf a 

red e I * I =«■ 9 |- x . 

red e,*: i * t e , t I - x 

Notice the difference in role between the constant x and the variable X. The first 
reduction proves the base case of the induction, using the theorem of constants 
for the universally quantified variable X. In order to prove the induction step, 
we first applied the theorem of constants for the universally quantified variables 
E and T. then added P( t) to the hypothesis (the equation *‘eq t |= x = t |- 
X and then reduced VU t) using again the theorem of constants for the 
universally quantified variable X. Like in the proofs of the lemmas, we merged 
the two proofs to save space. 

5 Conclusions and Future Work 

We have presented a finite trace semantics of LTL in the Maude logic together 
with a much more efficient version based on formula transforming state changes. 
The formula transformation approach can be regarded as a self contained result 
with interest to at least the rewriting and temporal logics communities. However, 
what perhaps makes it more interesting is that its integration into the general 
program monitoring framework JPaX seems to be quite efficient for practiced 
purposes, allowing an elegant flexibility in the choice and design of requirement 
languages. This can be useful not only for research projects and educational 
purposes, but also for real-life projects, where requirement languages may be 
domain or application specific. In principle what Maude provides is a static 
parsing environment for defining syntax, combined with a rewrite-based dynamic 
execution environment for defining efficient semantics over the parse trees. 

A current research activity is, however, to find yet more efficient representa- 
tions of future time LTL formula for the purpose of achieving an absolute optimal 
algorithm for testing their satisfaction on execution traces. This becomes espe- 
cially crucial for an implementation in a standard programming language such as 
Java. In [13] we describe such a provably minimal finite state machine represen- 
tation. An efficient dynamic programming algorithm is furthermore described in 
[22], although it examines the trace backwards, requiring the trace to be stored. 

As it turns out, this algorithm applies more naturally to the checking of past 
time LTL, since this can be done by a forward examination of the trace. Of fu- 
ture work can be mentioned that we will experiment with new logics in Maude, 
such as interval and real time logics and LML notations. We have already in [12, 
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As described in [12, l.‘>| JP.\X provides in addition to specification loused rnou- 
itorin^- also a capability of checking error patterns in multi-threaded programs. 
Future work will try to develop new algorithms for detecting other kinds of con- 
currency errors than data races and deadlocks. This includes studying completely 
new functionalities of the system, such as guided execution via code instrumen- 
tation to explore more of the possible interleavings of a non-deterministic con- 
current program during testing. Last, but not least, program monitoring can not 
only be applied during program testing, but, perhaps more interestingly, during 
operation, and be used to influence the program behavior in case requirements 
get violated. Our future research will focus on this aspect. 
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